ftp.cs.arizona.edu/ftp.cs.arizona.edu.tar/ftp.cs.arizona.edu/icon/newsgrp/group95b.txt/000078_icon-group-sender _Sun Jul 9 10:26:11 1995.msg

Internet Message Format | 1995-09-18 | 2KB

Received: by cheltenham.cs.arizona.edu; Sun, 9 Jul 1995 18:17:55 MST
From: Nick Williams <[e-mail]>
Message-Id: <[e-mail]>
Subject: Closures in Icon? Is it too late for a new feature to creep in?
To: [e-mail]
Date: Sun, 9 Jul 1995 10:26:11 -0400 (EDT)
X-Mailer: ELM [version 2.4 PL23]
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Content-Length: 1835
Errors-To: [e-mail]


One of the various features of LISP that I absolutely love is closures,
or, more accurately, the ability to produce new functions dynamically.
I'd like to see something like that in Icon, except that I'm not about
to propose anything like LISP's eval or even true LISP closures, but how
about this:

procedure TestClosure(var1, var2, ...)
environment catch_this_var, and_this_one

  ...
end

procedure MakeTestClosure()
local catch_thisvar, and_this_one

  ...
  return closure(TestClosure)
end

The 'closure' function would make a copy of the 'catch_this_var' and
'and_this_one' descriptors and store them in a new b_proc structure
(procedure header). The variables declared in the 'environment' clause
are equivalent to static, and are initialized to &null unless the
function is closed over inside a function which has local variables of
the same name, or unless there are globals of those names with values
other than &null; additionally, the closure() function could perhaps
take extra arguments to initialize any remaining, non-caught closure
variables. By not storing references to the variables closed over we get
semantics very different from LISP's: not real closures, but better than
nothing, and it would be easy to implement (a few mods to h/rstructs.h,
the GC, a few other places and the 'closure' function I bet).

This scheme could probably be extended a bit so that multiple functions
could share one 'environment' (by defining the 'environment' outside the
procedure declaration and giving it a name, declaring the participation
in that environment declaration in the procedure defs, and having
closure() take multiple procedure arguments and so on).

Wouldn't Icon be more interesting this way? :)

Nick

PS: forgive my terminology, I know it's loose, but I'm not at home,
    where I have all my comp. sci. books.

y comp. sci. books.